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REMARKS 

This Application has been carefully reviewed in light of the Final Office Action 
mailed October 4, 2006. At the time of the Final Office Action, Claims 1-12 and 14-22 were 
pending in this Application. Claims 1-12 and 14-22 were rejected. Claim 13 was previously 
cancelled without prejudice or disclaimer. Applicants respectfully request reconsideration 
and favorable action in this case. 

Claims 1-4. 6, 9-11, 16-18, and 22 are Allowable. 

Claims 1-4, 6, 9-11, 16-18, and 22 were rejected under 35 U.S.C. §103(a) as being 
unpatentable over U.S. Patent Application Publication 2002/0161868 issued to 
Chakkalamattam J. Paul et al. ("Paw/"), in view of U.S. Patent 5,974,547 issued to Yevgeniy 
Klimenko ("Klimenko"). 

Applicants respectfully traverse and submit that the proposed combination of Paul 
and Klimenko, even if proper (which Applicants do not concede), does not render Applicants 
claims obvious, for at least the reasons discussed below. 

In order to establish a prima facie case of obviousness, the references cited by the 
Examiner must disclose all claimed limitations. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 
(C.C.P.A. 1974). Paul and Klimenko, whether considered alone or in combination, fail to 
teach or suggest at least the following limitations recited in Applicants' Claim 1 : 

• receiving a unique identifier (UID) at a cluster controller from each of 
a plurality of hosts in communication with the cluster controller, while at 
least one of the plurality of hosts is executing in a pre boot execution 
environment; 

The Examiner alleges that this limitation is disclosed at Paul, paragraph 32. (Final 
Office Action, page 3). However, paragraph 32 of Paul simply discloses: 

[0032] PXE specifies the protocols by which a client requests and 
downloads an executable image from a boot server. PXE does not specify 
the operational details and functionality of the network bootstrap program 
(NBP) that the client receives from the server, i.e. the remote boot image 
downloaded by the PXE client via TFTP or MTFTP (Multicast TFTP). In 
general, the execution of the downloaded NBP initiates a series of 
processing steps on the client that ultimately will result in the client being 
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ready for use by its user. Typically, the NBP will use an application 
program interface (API) specified by PXE and provided by the client PXE 
support to request and install additional files via M/TFTP from the boot 
server containing executable images of an operating system, appropriate 
communications and other device drivers, and other system software. The 
NBP will then transfer client execution to the operating system which can 
use either PXE or its own communications support to request user-specific 
configuration information and application software executable images 
from the boot server for installation on the client. 

This passage merely explains that the Preboot Execution Environment (PXE) 
specifies the communication protocols that a client may use to request a network bootstrap 
program (NBP) from a boot server, and that when executed, the NPB requests and installs 
additional files from the boot server in order to ready the client for use. 

The passage discloses nothing that could be equated with a " unique identifier (JJJD) " 
much less "receiving a unique identifier (UID) at a cluster controller from each of a plurality 
of hosts," as recited in Claim 1. If the Examiner wishes to maintain this rejection, Applicants 
request that the Examiner indicate precisely which element recited in Paragraph 32 of Paul 
can allegedly be equated with the "unique identifier (UID)" that is received at a cluster 
controller from each of a plurality of hosts. 

As another example, Paul and Klimenko fail to teach or suggest the following 
limitation recited in Claim 1 : 

• in response to receiving the UIDs, causing the plurality of hosts to 
produce ready signals ; (emphasis added) 

The Examiner alleges that this limitation is disclosed at Paul, paragraph 35. (Final 
Office Action, page 3). However, paragraph 35 of Paul simply discloses: 

[0035] In the PXE protocol, DHCP option fields are used to perform 
the following: (a) distinguish between DHCPDISCOVER and 
DHCPREQUEST packets sent by a client as part of this extended protocol 
from other packets that the DHCP server or boot server might receive; (b) 
distinguish between DHCPOFFER and DHCPACK packets sent by a 
DHCP or Proxy DHCP server as part of this extended protocol from other 
packets that the client may receive; (c) convey the client system's ID (in 
most cases, the client's UUID~Universally Unique Identifier) to the 
DHCP and boot server; (d) convey the client system's architecture type to 
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the DHCP server and boot server; and (e) convey the boot server type 
from which the client is requesting a response. Based on any or all of the 
client network adapter type, system architecture type, and client system 
ID, the boot server returns to the client the file name (on the server) of an 
appropriate NBP executable. The client downloads the specified NBP 
executable into memory and then executes it. As noted above, the 
functionality within the downloaded NBP is not specified by the PXE 
protocol. 

The passage fails to disclose " causing the plurality of hosts to produce ready signals /' 
much less doing so "in response to receiving [unique identifiers from each of the plurality of 
hosts]," as recited in Claim 1. If the Examiner wishes to maintain this rejection, Applicants 
request that the Examiner indicate precisely which action disclosed in Paragraph 35 of Paul 
can allegedly be equated with " causing fal plurality of hosts to produce ready signals ," in 
response to receiving unique identifiers from each of the plurality of hosts. 

As yet another example, Paul and Klimenko fail to teach or suggest the following 
limitation recited in Claim 1 : 

• in response to receiving the user input from a first host, associating a 
first host name with the UID for the first host ; (emphasis added) 

The Examiner alleges that this limitation is disclosed at Paul, paragraph 35. (Final 
Office Action, page 3). Paragraph 35 of Paul is reproduced above. 

Paragraph 35 fails to disclose a client having both a "host name" and a "unique 
identifier (TJID)" for a particular host , much less associating the host name with the "unique 
identifier (UID) for the particular host. Further, Paragraph 35 fails to disclose making any 
association of names or identifiers for a host "in response to receiving . . . user input from 
[the] host." If the Examiner wishes to maintain this rejection, Applicants request that the 
Examiner indicate precisely which elements disclosed in Paragraph 35 can be equated with 
the "first host name" and the "unique identifier (UID)" for a first host, as well as the 
operation disclosed in Paragraph 35 that can be equated with associating a "first host name" 
with the "unique identifier (UID)" for a first host. 
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As yet another example, Paul and Klimenko fail to teach or suggest the following 
limitation recited in Claim 1 : 

• after associating the first host name with the UID for the first host, 
causing the first host to produce a completion signal; 

The Examiner alleges that this limitation is disclosed at "(Paul, )" (Final Office 
Action, page 3). Applicants assume that the Examiner either forgot to include the paragraph 
reference, or could not find any portion of Paul that could be equated with this limitation of 
Claim 1 . In any event, the rejection is improper because the Office Action fails to cite the 
prior art with sufficient specificity under 35 U.S.C. § 132 and 37 C.F.R. § LI 04 to allow 
applicants to adequately respond to the rejections. 

First, the Office Action does not comply with the intent and purpose of 35 U.S.C. § 
1 32 because it fails to properly identify and clearly explain the portions of the cited prior art 
that allegedly teach the limitation of Claim 1 recited above. 

In addition to defeating the intent and purpose of 35 U.S.C. § 132, Applicants 
respectfully submit that the Office Action's lack of specificity renders the Office Action non- 
compliant with the requirements of 37 C.F.R. § 1.104. 

37 C.F.R. §1.104 states: 



In rejecting claims for want of novelty or obviousness, the 
examiner must cite the best references at his or her command. 
When a reference is complex or shows or describes inventions 
other than that claimed by the applicant, the particular part 
relied on must be designated as nearly as practicable. The 
pertinence of each reference, if not apparent, must be clearly 



explained and each rejected claim specified. 

37 C.F.R. § 1.104(c)(2) (emphasis added). 

Because the Office Action fails to cite any particular portion of Paul that allegedly 
teaches the limitation of Claim 1 recited above, the Office Action fails to comply with both 
35 U.S.C. § 132 and 37 C.F.R. § 1.104. 
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As still another example, Paul and Klimenko fail to teach or suggest the following 
limitation recited in Claim 1 : 

• repeating the operations of receiving replies from hosts, associating 
host names with UIDs, and causing hosts to produce completion signals, 
until each of the plurality of hosts has been named, such that the user 
input dictates the order in which host names are assigned to the multiple 
hosts, (emphasis added) 

The Examiner alleges that these limitations are disclosed at Paul, paragraphs 52 and 
64. (Final Office Action, pages 3-4). Paragraph 52 of Paul discloses that PXE clients 
broadcast initial request packets in a network with redundant boot servers. An initial request 
packet broadcast from a PXE client is received by all boot servers in the network. Any of the 
boot servers having a properly configured DHCP server service can respond to the initial 
broadcast request packet. The PXE client can receive one or more boot server responses and 
choose a response which directs it to a boot server to complete its remote boot. 

Paragraph 64 of Paul discloses that a determination is made regarding the availability 
of a local server for booting additional clients and the availability of other servers that have 
reported that they are booting additional clients. A determination is then made as to whether 
or not a PXE Proxy service is currently executing. 

Thus, these paragraphs fail to disclose "associating host names with UIDs" or 
"causing hosts to produce completion signals." These paragraphs also clearly fail to disclose 
repeating a set of operations "until each of the plurality of hosts has been named, such that 
the user input dictates the order in which host names are assigned to the multiple hosts ." 
Nothing in Paragraphs 52 or 64 of Paul discloses a user dictating the order in which host 
names are assigned to multiple hosts. 

As still another example, Paul and Klimenko fail to teach or suggest the following 
limitation recited in Claim 1 : 

• receiving user input from a first host among the plurality of hosts, the 
user input comprising notification of the insertion of a disk within the 
first host; (emphasis added) 
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The Examiner alleges that this limitation is disclosed at Klimenko, Col. 4, lines 17-63. 
(Final Office Action, page 4). However, Column 4, lines 17-63 of Klimenko merely recites: 

While the boot process is occurring but prior to the availability of any 
client O/S-based network support, client hard disk emulation occurs through 
appropriate calls made to an interrupt (Interrupt 13 or simply "Int 13") handler. 
Through such calls, appropriate sectors in the client image file are initially 
downloaded, via a real-mode network adapter (NIC) driver and the Int 13 
Handler to remotely install various components of the O/S into client PC. The 
actual client hard disk emulation process is provided through a real mode 
procedure that executes as part of Int 13 Handler. In essence, the real mode 
procedure determines, based on values of status flags, whether the client O/S is 
then capable of handling a network request for sector access of the client image 
file. If the client O/S has not then progressed to that point in its boot process, 
the real mode procedure processes that request, in real mode, through the Int 13 
Handler. 

As a client O/S kernel is installed and initialized during the boot 
process, the kernel installs and activates various device drivers, including the 
inventive LANHDVSD.VXD procedure. This procedure is compliant with 
both the Int 13 Handler and with the O/S, specifically, in the case of Windows 
95 O/S, a network driver (NDIS— network driver interface specification) kernel 
therein and the O/S input/output subsystem (IOS). The inventive procedure, 
which executes as a protected mode driver, contains two asynchronous 
procedures. These asynchronous procedures, by setting and testing appropriate 
flags used as processing state semaphores, collectively control the transition of 
hard disk requests to the networked client image from the Int 13 Handler to the 
client O/S depending upon, as the client O/S is then booting, the O/S resources 
that are then available. During early phases of the boot process, insufficient 
O/S components have been loaded and activated to provide client O/S 
supported network access. Consequently, client hard disk access requests are 
handled through the Int 13 Handler. Whenever sufficient O/S resources 
become available to permit network access through the client O/S, the 
asynchronous procedures permit these requests to be serviced by the NDIS and 
IOS components of the client O/S, so as to provide O/S supported network 
access, rather than by the Int 13 Handler. Hence, these asynchronous 
procedures collectively assure, in conjunction with Int 13 Handler, seamless 
and continuous client hard disk emulation during the real-protected transitory 
state. 

This passage fails to disclose anything regarding the insertion of a disk within a host , 
much less receiving a " notification of the insertion of a disk within Tal host ." In fact, the only 
mention of a disk in the cited passage regards a "client hard disk emulation process," which 
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does not concern the insertion of a disk within a host or a notification of such an insertion of 
a disk. Thus, Klimenko does not disclose the limitations of Claim 1 alleged by the Examiner. 

For at least these reasons, Paul and Klimenko, whether considered alone or in 
combination, fail to teach or suggest several limitations recited in Claim 1 . Thus, Applicants 
respectfully request reconsideration and allowance of Claim 1, as well as Claims 2-8 that 
depend from Claim 1 . In addition, for analogous reasons, Applicants request reconsideration 
and allowance of independent Claims 9 and 16, as well as Claims 10-12, 14-15, and 17-21 
that depend therefrom. 
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CONCLUSION 

Applicants have now made an earnest effort to place this case in condition for 
allowance in light of the amendments and remarks set forth above. Applicants respectfully 
request reconsideration of Claims 1-12 and 13-21. 

Applicants encloses a Petition for Extension of Time for one month and authorize the 
Commissioner to charge the amount of $120.00 to Deposit Account No. 50-2148. 

Applicants believe there are no additional fees due at this time. However, the 
Commissioner is hereby authorized to charge any fees necessary or credit any overpayment 
to Deposit Account No. 50-2148 of Baker Botts L.L.P. 

If there are any matters concerning this Application that may be cleared up in a 
telephone conversation, please contact Applicants' attorney at 512.322.2689. 

Respectfully submitted, 
BAKER BOTTS L.L.P. 
Attorney for Applicants 

Eric M. Grabski 
Reg. No. 51,749 

Date: February 5. 2007 

SEND CORRESPONDENCE TO : 
Baker Botts l.l.p. 

CUSTOMER ACCOUNT NO. 31625 

512.322.2689 

512.322.8320 (fax) 
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